Node / meshtastic / Meshtastic-Android / files / docs / en / developer / architecture.md

Displaying Rendered • View raw • Download

title: Architecture

parent: Developer Guide

nav_order: 1

last_updated: 2026-06-11

aliases:

• layers

• module-architecture

• kmp

• radio-control

The Meshtastic Android and Desktop apps follow a modular Kotlin Multiplatform (KMP) architecture with clear layer boundaries (iOS is currently a compile-only validation target — there is no shipping iOS app yet).

T282828

The Android application entry point:

• Activity, Application, and Manifest definitions

• Koin DI module composition (T383838AppKoinModule)

• Flavor-specific bindings (T383838google/, T383838fdroid/)

• Android-only integrations (widgets, services)

The Desktop (Linux/macOS/Windows) entry point:

• Compose Desktop window management

• Desktop-specific DI (T383838DesktopKoinModule)

• Platform stubs for Android-only capabilities

• BLE (Kable), Serial, and TCP transport implementations

Each T383838feature/ module owns a vertical slice of functionality:

Feature modules:

• Use the T383838meshtastic.kmp.feature convention plugin

• Depend on T383838core modules, never on other T383838feature modules

• Own their navigation entries and DI registrations

• Contain platform-specific implementations in T383838androidMain/T383838jvmMain/T383838iosMain

Shared infrastructure used by all features:

Protobuf models are no longer a local module — they come from the external T383838org.meshtastic:protobufs Maven artifact (pinned in T383838gradle/libs.versions.toml).

Each module uses the standard KMP source set hierarchy:

T282828

• No T383838android.* imports in T383838commonMain

• Platform-specific code goes in appropriate source set

• Prefer interfaces + DI over T383838expect/T383838actual for complex behaviors

• Use T383838expect/T383838actual only for simple declarations

The project uses Koin with annotation processing:

• T383838@Module, T383838@Single, T383838@Factory annotations

• T383838@ComponentScan for automatic registration

• Feature modules export their own T383838Feature*Module class

• App/Desktop compose all modules in their root DI configuration

Features issue radio commands through T383838RadioController (T383838core:repository), a composite of four

focused sub-interfaces so callers can depend on just the slice they need:

T383838RadioControllerImpl (T383838core:service) is the in-process composition root for all targets

(Desktop, iOS, single-process Android). It assembles the four sub-controllers via Kotlin interface

delegation and adds the cross-cutting concerns (connection state, packet-id, location,

device-address switching). Commands are direct suspend calls; admin writes are fire-and-forget

because the device is the source of truth (local persistence is an optimistic cache). The layered

shape mirrors the meshtastic-sdk

T383838AdminApi/T383838TelemetryApi design to ease a future SDK migration.

T383838ServiceRepository is the reactive bridge between the mesh service and all feature/UI layers.

It is decomposed into focused provider interfaces following the Interface Segregation Principle:

T383838ServiceRepository extends all four interfaces — consumers inject the narrowest interface

they actually need. For example, T383838ContactsViewModel injects only T383838ConnectionStateProvider

rather than the entire T383838ServiceRepository, preventing accidental access to write operations

from UI code. T383838RadioController also extends T383838ConnectionStateProvider so VMs that already

inject a controller sub-interface can read connection state without a separate dependency.

Navigation uses Navigation 3 with typed routes:

• All routes defined in T383838core/navigation/Routes.kt

• Routes are T383838@Serializable data classes/objects

• Deep links resolved through T383838DeepLinkRouter

• Each feature registers its own navigation entries

See Navigation & Deep Links for details.